feat(parquet): add bytes_processed scan-completion metric - #24524

`EXPLAIN ANALYZE` reports how many row groups a scan pruned, but nothing
reports how much of a scan is done. `bytes_scanned` looks like it should
serve — its natural denominator, the size of the files in the plan, is
known up front — but it counts only the bytes fetched, so pruning and
projection pushdown leave it understating progress by a factor that
varies per query.

`bytes_processed` completes that numerator: it counts the bytes a scan is
finished with, whether it read them or proved it did not need them. Over
the lifetime of a file it advances by exactly that file's size — or, for
a file split into byte ranges for parallelism, by the size of the range —
so `bytes_processed / total file bytes` is a completion fraction a
progress reporter can use directly.

Credit lands a row group at a time. Row groups pruned while opening the
file (by range, statistics, bloom filter, page index or limit) are
credited before the first batch is decoded, which is the progress a
scan makes that `files_processed` cannot show; row groups dropped
mid-scan by a dynamic filter are credited as they are dropped; the rest
are credited as the decoder reaches them. Whatever is left over is
credited when the file closes, so a scan cut short by a `LIMIT`, an
early stop or an error still ends on exactly the size of its range.

Costs one atomic add per row group. Crediting a row group's bytes
progressively as its rows decode is left to a follow-up.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017cmj1SUoV7Y9ADPbzLrzZ3

Two fixes from review of the `bytes_processed` metric.

`EarlyStoppingStream` returned `None` once a dynamic filter proved the
rest of a file irrelevant, but went on holding its inner stream. The
decoder's drop is what credits the range's remaining bytes, so the file
kept reading as partly unread after the scan had demonstrably finished
with it — for however long the caller took to drop the wrapper. Hold the
inner stream in an `Option` and release it when marking the stream done,
which also frees the decoder's buffers at the point we stop reading
rather than later. The same applies when the inner stream is simply
exhausted.

`ByteProgress` tracked its remaining budget as a `u64` while crediting a
`Count`, which stores a `usize`. On a 32-bit target a credit above
`usize::MAX` would decrement the budget in full while recording a
saturated value, so the two could disagree and the metric would never
reach the range size. Hold the budget at the counter's width instead, so
an oversized range saturates once, at construction. `bytes_scanned` has
the same ceiling; representing byte counters as `u64` would be a change
to the core metric types, not to this scan.

Both are covered by tests that fail without the corresponding fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017cmj1SUoV7Y9ADPbzLrzZ3

Review suggestion: the row groups left in `rg_plan` are a subset of the
ones this range owns, because the plan they came from had
`prune_by_range` applied. Subtracting the planned bytes from the range's
total therefore leaves exactly the skipped ones, with no need to build a
lookup of which row groups the plan kept.

Also pin the property the in-range filter exists for: with nothing pruned
a split file's ranges must credit nothing at open, since every row group
a range owns is one it will read and the rest belong to its sibling. The
existing assertions could not catch a range crediting its sibling's row
groups — the drop-time top-up brings the total back to the range size
either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017cmj1SUoV7Y9ADPbzLrzZ3

Adding a `pub` field to `ParquetFileMetrics` is a semver-breaking change
for anyone constructing it with a struct literal, which cargo-semver-checks
reports and reviewers have flagged. The field also turned out to earn
nothing: once file-level pruning started crediting through the progress
guard, the only thing left reading it was the guard's construction.

Build the counter on demand instead, next to the other metrics in this
file that are registered where they are used rather than held on the
struct. The public API is unchanged, so the semver break goes away, and
future metrics of this kind need not widen it either.

`EXPLAIN ANALYZE` output is unaffected: the counter keeps its name, type,
category and filename label, so it renders in the same position. The
sqllogictest expectations are unchanged and still pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017cmj1SUoV7Y9ADPbzLrzZ3

Building the counter on demand rather than storing it on
`ParquetFileMetrics` left three intra-doc links pointing at a field that
no longer exists, which fails rustdoc under `-D warnings`.

Repointing them at the struct alone would lose the information, because
there is now no Rust item that carries the metric's contract: consumers
reach it by name through the plan's metrics set, and nothing said so
anywhere rustdoc renders. So the fix is to document it on
`ParquetFileMetrics` itself -- why it is not a field, how to read it, and
what its sum means -- and point the three links there.

Also records the caveat the metric's obvious use invites: it counts work
resolved, not time spent. Pruned bytes are credited as soon as they are
proved unnecessary, and proving that is nearly free, so the ratio is the
right numerator for a progress bar and only a rough one for predicting
how much longer a query will run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017cmj1SUoV7Y9ADPbzLrzZ3